Internet Surfer 2.0

home *** CD-ROM | disk | FTP | other *** search

/ Internet Surfer 2.0 / Internet Surfer 2.0 (Wayzata Technology) (1996).iso / pc / text / mac / faqs.112 < prev next >

Wrap

Text File | 1996-02-12 | 27.8 KB | 684 lines

Frequently Asked Questions (FAQS);faqs.112 One goal is to offer discussion groups for students who learn by tossing ideas around and discussing them, asking each other and helping each other out. One possible goal is to create and archive learning material (tutorials, exercies) itself. One possible goal is to offer possibilites for tutors and students to find each other for email teaching. 4. Administration There are decisions to be made concerning the process of creation of newsgroups, possible moderation of them, how to divide topics and disciplines, how to handle possible (probable) flame wars and other possibly destructive phenomena, and so on. Some kind of a decision-making process will need to be established for these. To be compatible with the goals and principles of UU, some kind of a groupware decision-making support system would be useful to help the process. To better classify information exchange and to provide feedback for participants, some kind of accreditation / peer review system is desirable. Here again groupware mechanisms and tools would be useful for being compatible with the openness principles, dividing work and avoiding single point of failure. 5. Copyright on the articles and learning material According to the Berne convention, the author has the copyright on his or her work. If a base of learning material is created, copyright is a relevant issue - should a "Usenet University" trust be created which holds the copyright, should the authors have the copyright with some kind of a GNU-like copyright, should the authors have the copyright and give other only the right to copy the documents in the UU context, should the created documents be put in the public domain. There are lots of possibilities and at least if the aim is to create a big base of material some guidelines need to be established. 6. Technology Technology which people os Usenet have varies widely. Many have text-only 80 x 24 character displays, while many have workstations with big graphics screens with perhaps also color and sound, and software for multi-media email. This needs to be addressed - for topics like learning to speak languages, for example sound can be an essential part and transmitting sounds on UU would be very beneficial. Besides the capabilites of the media, access to on-line resources such as ftp servers, archie, www, wais servers, newsgroup archives and other services on the Internet varies. Some only have a Usenet feed with little possibility to access on-line services, some have very fast lines to the rest of the world and some are in between. These differences probably will divide discussions a bit - for learning of languages for example it could be useful to have a separate group for those who have sound capabilities, to avoid frustration on the part of those with no such access. 7. Disciplines or division of topics There are several possibilities for how to divide topics handled in UU. There is the discipline division of the scientific community, there are various classifications used by libraries, there is the Usenet newsgroup division, etc. It probably is not wise to use strictly just any one of these divisions, but it would seem useful to borrow from many of them. This is an issue which needs discussing. 8. Later steps To get things rolling with respect to full-fledged course on UU, we should discuss suggestions for topics you think would be good as "prototype topics", with suggestions for group names. These topics should be ones for which there are enough people interested on to reach "critical mass" to develop the course material. One possibility would be to take a topic for which there already is reference material for - some newsgroups on Usenet have excellent FAQs with literature references, answers to many questions, hints from old-timers etc. which could offer a good start for a tutorial and/or a course run by teachers on the topic. It probably will be desirable to have a few groups for each topic. An example division would be to have one group for generic discussions and one for material references / exercises / other "carefully-written" articles standing on their own. Alternatively a system of keywords in the Subject field could be adopted (like used in sci.virtual-worlds) to mark the type of each article, but for unmoderated groups it would be hard to maintain the practice. 9. What to do to keep the UU ball rolling and growing? For all who are willing to support the idea of UU and possible similar community projects / resources (like a community effort encyclopaedia, dictionaries between different languages), the thing to do is to _contribute_ something - just a simple thing like drafting a two dozen-item itemized list of subtopics on a thing you know something about and which you think could be turned into a document for others to read and help them learn. Then others could fill in things on the document, and with each person contributing just a relatively small amount of work, something just might come out of it. Another thing to do would be to point out the UU idea and UU groups to people on other Usenet groups on topics you're interested in - many Usenet groups have FAQ's which are good information resources on the topic field, and the UU groups could be used as a media to develop those FAQ's. ---------------------------------------- Current newsgroups These groups (all but alt.uu.future created 22 July 1992) are part of the Usenet University. For futher information on UU, see directory pub/doc/uu on the machine nic.funet.fi. A "material" group means that the group exists for postings of course material, announcements, pointers to material and resources, essays, etc. relevant to the "department" of the group and/or the topic. This group is for one-time articles / posts - discussions are _not_ suitable for this newsgroup but should instead be held in a corresponding .misc group. Followups should be directed and posted there. On some UU groups (where there is a volunteer teacher / teachers) the material will be mostly for course-like work, on others for self-study, on others the main info will be something else. The conventions will form as time passes and while there are none, a wide range of relevant postings will appear. Later, different styles of learning will perhaps spin off different newsgroups. A "misc" group exists for discussions on learning, followups on the "material" group articles, and other discussion relevant to the department or topic. For all departments / topics, there are as of yet no "material" groups but instead only .misc groups - in that case, articles fitting in the material group should be posted with "MATERIAL" as the first word in the Subject: field of the article. There are two ftp archives of the Usenet University newsgroups - one on nic.funet.fi, directory pub/archive and another at ftp.coe.montana.edu (192.31.215.240) in pub/uu/... For now at least the archives don't have articles from the epoch of UU but instead from a later point in time. The following groups have been created 1992, July 22nd: alt.uu.lang.misc Language department of Usenet University This is a group for the "language department" of UU. This is the "main group" for learning languages, linguistics etc. - later there will be more specific groups for different topic in the field. alt.uu.math.misc Math department of Usenet University This is a group for the "math department" of UU. This is the "main group" for learning mathematics - later there will be more specific groups for different topic in the field. alt.uu.comp.misc Computer department of Usenet University This is a group for the "computer department" of UU. This is the "main group" for learning things to do with computers - later there will be more specific groups for different topic in the field. Both "computing science" and "using computers as tools" topics are suitable under this department, at first at least. Some of the computing science topics perhaps will fit better under math - the choice is left to each participant. alt.uu.lang.esperanto.misc Study of Esperanto in Usenet University This is a group for learning Esperanto. This is the "main group" for learning Esperanto - later there will be more specific groups for different topics in the field. alt.uu.misc.misc Misc. department of Usenet University This is a group for learning about topics not suitable for other groups of UU. This is the "catch-all" group, "misc department" of UU. alt.uu.virtual-worlds.misc Study of virtual worlds in Usenet University This is a group for learning about virtual worlds or virtual reality. alt.uu.tools Tools for Usenet University and education This is a group for discussing tools useful in UU and self-education / distance education, what tools are recommended to be used with UU, what tools are helpful, where to get such tools, etc. Examples of the tools include machinery for viewing languages other than English on computers, possible UU "courseware" (for studying UU course pacakges) etc. alt.uu.announce Announcements of Usenet University This is a group for announcements of UU. alt.uu.future Planning the future of Usenet University This functions as a group to discuss the future of UU, and currently also as a "misc" group in which generic meta-discussions of UU take place. The first UU group, created in June 1992. ---------------------------------------- Feel free to use the UU groups! //Jyrki Xref: bloom-picayune.mit.edu comp.unix.sysv386:29504 comp.unix.bsd:9884 comp.os.mach:2806 news.answers:4460 Path: bloom-picayune.mit.edu!enterpoop.mit.edu!spool.mu.edu!wupost!darwin.sura.net!jvnc.net!netnews.upenn.edu!dsinc!bagate!cbmvax!snark!esr From: esr@snark.thyrsus.com (Eric S. Raymond) Newsgroups: comp.unix.sysv386,comp.unix.bsd,comp.os.mach,news.answers Subject: Known Bugs in the USL UNIX distribution Message-ID: <1jjQl4#37x4q01WY07X85d4Xb1vMd0g=esr@snark.thyrsus.com> Date: 7 Dec 92 19:48:45 GMT Expires: 20 Feb 93 00:00:00 GMT Sender: esr@snark.thyrsus.com (Eric S. Raymond) Followup-To: comp.unix.sysv386 Lines: 1158 Approved: news-answers-request@MIT.Edu Archive-name: usl-bugs Last-update: Mon Dec 7 14:40:22 1992 Version: 9.0 What's new in this issue: * Fix availability for ndbm. (In the table below, bugs new this issue or old bugs for which information has been added are marked with a * at the left margin) 0. Table of Contents I. Introduction II. General Bugs 1. Dropout problems with tty devices 2. Suid programs dump core when signalled 3. DMAs on large ISA machines may fail 4. There is a cylinder limit on disk size 5. shmat(2) vs. vfork(2) 6. X performance problem 7. FIONREAD fails on regular files 8. A security hole in login 9. COFF problems with long filenames 10. Flakeouts in the Wangtek device driver 11. A kernel declaration bug 12. fread(3) does the wrong thing on pipes and FIFOs 13. Process accounting is broken 14. tar(1) foos up in the presence of symbolic links 15. Symbolic links can interfere with shellscript execution 16. Piping a csh builtin causes the shell to hang. 17. Quick port setup option in sysadm is broken 18. COFF binaries linked with curses(3) and shared libc hang 19. shl hangs, sxt devices bad 20. num-lock prevents mouse from working properly 21. adjtime() doesn't work 22. ttymon drops DTR 23. cron mail doesn't go through aliasing 24. fragility in xterm 25. csh lossage due to bad optimization 26. Bug in cp(1) 27. tbl -me doesn't work 28. who -r fragility leads to boot-time problems 29. at(1) breaks here-documents in shell scripts III. Networking and File-Sharing Bugs 1. NFS locking is unusably slow 2. UFS file system problems 3. Byte-order problem with NFS when accessing Sun disks 4. Under weird circumstances, lseek on UFS may cause corruption 5. FTP problems 6. A bug in the WD80x3 support IV. SCSI Support Problems 1. sar is confused by SCSI 2. A configuration problem 3. Synchronous SCSI hang problem 4. ps chokes on commands that do SCSI I/O 5. Transfer speed problems with Adaptec 1542B on 486s V. Development Tools Problems 1. General UCB library brokenness 2. USL emulation of BSD signals doesn't work 3. Possible string library problems * 4. USL's ndbm support is broken. 5. An include file is missing 6. sscanf(3) has a potential bug 7. Compiler problems VI. The FUBYTE Problem VII. Destiny and Dell I. Introduction This posting lists known bugs in System V Release 4 implementations, and known fixes applied by various porting houses (there's also random bits of information about SCO UNIX here and there). It was formerly part of the 386-buyers-faq issues 1.0 through 4.0, and is still best read in conjunction with the pc-unix/software FAQ descended from that posting. This document is maintained and periodically updated as a service to the net by Eric S. Raymond <esr@snark.thyrsus.com>, who began it for the very best self-interested reason that he was in the market and didn't believe in plonking down several grand without doing his homework first (no, I don't get paid for this, though I have had a bunch of free software and hardware dumped on me as a result of it!). Corrections, updates, and all pertinent information are welcomed at that address. This posting is periodically broadcast to the USENET group comp.unix.sysv386 and to a list of vendor addresses. If you are a vendor representative, please check to make sure the information on your company is current and correct. If it is not, please email me a correction ASAP. If you are a knowledgeable user of any of these products, please send me a precis of your experiences for the improvement of future issues. The bug descriptions often include indications of fixes by the various porting houses to their current releases. These are: Consensys UNIX Version 1.3 abbreviated as "Cons" below Dell UNIX Issue 2.2 abbreviated as "Dell" below Esix Revision A abbreviated as "Esix" below Micro Station Technology SVr4 UNIX abbreviated as "MST" below Microport System V Release 4.0 version 4 abbreviated as "uPort" below UHC Version 3.6 abbreviated as "UHC" below SCO Open DeskTop 1.1 abbreviated as "SCO" below II. General Bugs 1. Dropout problems with tty devices The most serious problem anyone has reported is that the USL asy driver is flaky and occasionally drops characters at above 4800 baud. Microport, Dell, Esix, and UHC say that they believe they've fixed this. However, Dell, at least, was mistaken when they first made this claim; a more detailed description of the problem is given below. I have been assured that this is on the fix list for the next Dell release. Bela Lubkin at SCO comments "386 interrupt latency vs. unbuffered UARTs. This is a tough problem. Nobody's driver should drop characters with a turned-on 16550. It's not so easy with a 16450. Anyone with 16450s or lower should be able to solve their problems by dropping in a 16550." 2. Suid programs dump core when signalled Mark Snitily of SGCS says that under many SVr4s, signalling a process that is running suid root will cause it to core-dump. He says Dell and MST have fixed this, and SCO doesn't suffer from this. 3. DMAs on large ISA machines may fail On ISA machines with more that 16MB of RAM, SVr4 may try to do DMA from outside the bus's address space, causing serious problems. UNIX ought to do an in-memory copy to within the low 16MB but the USL base code doesn't. Dell says they've fixed this, and that's been confirmed by a user. UHC says they've fixed this; they add that the special buffer-allocation logic to handle the problem can be turned off with a tunable kernel parameter if you've got less than 16M. Microport says they've fixed this in their new 4.1 release, shipping early March. Esix offers a patch to correct this problem. SCO used to have a similar bug but fixed it long ago. John Sully <jms@mport.com> writes: "This was due to a bug in pre version 4 dma code. The USL code has always at least attempted to do a copy from low memory to high memory on systems with more than 16Mb of RAM. By the way UHC is wrong; the buffer allocation code only comes into play if you have more than 16Mb of memory. You can turn it off if you have a machine (ie. an EISA bus) which will allow you to do DMA above 16Mb. You *must* have this tunable (MAXDMAPAGE) turned on if you are using *ISA* bus masters in a system with more than 16Mb of ram. Unfortunately doing this will affect all drivers which do dma as there is no good way to do this on a per-driver basis." 4. There is a cylinder limit on disk size Stock USL code is limited to 1,024 cylinders per Winchester, which might cause problems with some disk drives. Microport, Dell, Esix, MST, and UHC have fixed this. Bela Lubkin says "SCO's boot filesystem must lie below 1024 cylinder mark; anything else can be anywhere. This is more-or-less a limitation of the BIOS interface that the bootstrap loader must use. Could be circumvented by going directly to controller hardware in the bootstrap loader, but that would be horrendously complex with all the controllers & host adapters to be supported." This limit probably applies to all other UNIXes as well. 5. shmat(2) vs. vfork(2) The shmat(2) call is known to interact bady with vfork(2). Specifically, if you attach a shared-memory segment, vfork(), and then the child releases the segment, the parent loses it too! Workaround; use fork(2). UHC and Microport both suspect that they still have this bug and opine that anyone who uses vfork deserves to lose. Dell has no plans to fix it. John Sully <jms@mport.com> writes: "This is not a bug. It is completely consistent with the semantics of a change to the address space of the child. Think about it: any change to the address space of a child process created by vfork(2) is reflected in the parent since the child is actually executing in the parent's address space. Therefore if the child changes the address space (in this case by releasing the shared memory segment) what should happen? Right, the parent should have the same change happen. And what does happen? The segment is released in the parent. One can argue about the braindead semantics of vfork(2) all day, but the fact remains that this is exactly what one would expect to happen. To quote from the manual page: [...] vfork differs from fork in that the child borrows the parent's *memory* and thread of control until a call to execve or an exit (either by a call to exit or abnormally.) [ emphasis added ] and later: It does not work, however, to return while running in the child's context from the procedure which called vfork since the eventual return from vfork would then return to a no longer existent stack frame. Please note that the entire address space of the parent is used by the child created by vfork(2). The manual page also points out several other caveats involved in doing anything to the parent's address space except successfully calling an exec family function or _exit (note it specifically says *not* to call exit(2)). I do not believe that having a shared memory segment disappear from the parent's address space is out of line after reading the man page for vfork(2). It is interesting to note that Sun after implementing its new VM system in SunOS 4.0 initially had no plans to support vfork, since they felt that the COW semantics of the new fork would provide the necessary efficiency gain. Indeed they found that most programs which used vfork worked just fine by doing -Dvfork=fork. All that is, except for a certain popular command interpreter [ed: can you say C shell?]. So we are stuck with the legacy of this braindead system call. BTW, Microport has no plans to fix this :-)." 6. X performance problem Stock X11R4 and R5 (at least prior to 1.2E) is said to hog the processor if you use the LOCALCONNECT option. Jan Brittenson <bson@gnu.ai.mit.edu> posted the following workaround: I don't know what causes the standard X server to hog the CPU, but it can be avoided. Use the following program instead of xinit. Compile it with `$CC -O -o xserv xserv.c -lX11' where CC is either /usr/ccs/bin/cc or gcc. Set DISPLAY and XINITRC and run `xserv' from your home directory. This is just a q&d hack, and not really a substitute for xinit -- but it works. /* xserv.c -- start X server Start X server. Similar to xinit, but intended to circumvent the X386 CPU Hog Mode Jan Brittenson, June 2 1992 05:15 am */ #include <stdio.h> #include <sys/types.h> #include <signal.h> #include <setjmp.h> #include <unistd.h> #include <libgen.h> #include <X11/Xlib.h> #include <X11/Xos.h> #include <X11/Xmu/SysUtil.h> extern int errno; /* Start X server. Fork-exec server, passing the DISPLAY environment variable. Wait for server to get up and running (at which point it passes back a SIGUSR1), at which point the user xinitrc file is run. */ #define DEFAULT_XPATH "/usr/X386/bin/X386" #define XINITRC ".xinitrc" #define DEFAULT_XCOMMAND "xterm -g +1+1 -n login -display :0" extern void *malloc (), free (); extern char *basename (), *getenv (), *strcpy (); /* X stuff */ Display *top_display; /* This is supposed to be in libgen.a... */ static char *basename (s0) char *s0; { register char *s1; for (s1 = s0 + strlen (s0) - 1; s1 > s0 && *s1 != '/'; s1--); if (*s1 == '/') return s1+1; return s1; } jmp_buf sigusr1_frame; static void caught_sigusr1 (int dummy) { longjmp (sigusr1_frame, !0); } static char *dispname (s0) char *s0; { register char *s1; for (s1 = s0 + strlen (s0) - 1; s1 > s0 && *s1 != ':'; s1--); return s1; } /* No arguments */ int main (argc, argv) int argc; char **argv; { char *xserver_file, *xinitrc_file, *home_path, *display, *display_X_arg; int xserver_pid, orgmask; /* Not that it really matters, just to avoid being used as a direct replacement for xinit. */ if (argc != 1) { fprintf (stderr, "usage: %s\n", basename (*argv)); exit (1); } /* Resolve xinitrc path. This is done before the server is started. */ if (!(home_path = getenv ("HOME"))) home_path = "/etc"; if (!(xinitrc_file = getenv ("XINITRC"))) { xinitrc_file = malloc (strlen (home_path) + 1 + strlen (XINITRC) + 1); sprintf (xinitrc_file, "%s/%s", home_path, xinitrc_file); } else xinitrc_file = strdup (xinitrc_file); /* Resolve display */ if (!(display = getenv ("DISPLAY"))) display = display_X_arg = ":0.0"; else display_X_arg = dispname (display); /* Tell server to notify us when up and running */ signal (SIGUSR1, SIG_IGN); orgmask = sigblock (sigmask (SIGUSR1)); /* Start server */ if (!(xserver_pid = vfork ())) { xserver_file = DEFAULT_XPATH; execl (xserver_file, xserver_file, display_X_arg, NULL); fprintf (stderr, "%s: can't exec %s (errno = %d) -- start-up aborted\n", basename (*argv), xserver_file, errno); exit (1); } if (xserver_pid < 0) { fprintf (stderr, "%s: can't fork (errno = %d) -- start-up aborted\n", basename (*argv), errno); exit (1); } /* Await signal from server */ #if 0 /* Why the #@$*! doesn't this work?! */ sigsetmask (orgmask); alarm (20); sigpause (sigmask (SIGUSR1) | sigmask (SIGALRM)); #else sleep (5); #endif /* Open display */ if (!(top_display = XOpenDisplay (display))) { fprintf (stderr, "%s: unable to open display '%s' -- start-up aborted\n", basename (*argv), display); exit (1); } /* Execute xinitrc file */ if (system (xinitrc_file) < 0) system (DEFAULT_XCOMMAND); /* Close display */ XCloseDisplay (top_display); /* Terminate server */ kill (xserver_pid, SIGTERM); /* Finished */ free (xinitrc_file); } 7. FIONREAD fails on regular files Christoph Badura <bad@generics.ka.sub.org> reports that the FIONREAD ioctl() fails on regular (disk) files. He has sent USL a one-line kernel fix. 8. A security hole in login David Wexelblat <dwex@mtgzfs3.att.com> reports: "There is a HUGE security hole in /bin/login in all USL derived SVR4s before 4.0.4. Refer to CERT advisory CA-91:08, dated 5/23/91. This is known to be present in AT&T SVR4 2.1, and Microport SVR4 3.1. ESIX claims to have fixed it, Microport reports that it is fixed in 4.1. I won't give any more details unless necessary. Suffice to say that this bug allows any non-privileged user on an SVR4 system to get read-write access to any file on the system." 9. COFF problems with long filenames A source at Dell urges: "Our SVR4v2 did some stuff that USL didn't get around to until SVR4v4. Try Dell UNIX 2.1 with a COFF program on a large UFS filesystem in a directory with long names. Runs on Dell UNIX. Breaks on others." I don't have more definite info yet. 10. Flakeouts in the Wangtek device driver Dell reports that USL's Wangtek device driver is seriously flaky. "How'd you like a multi volume backup where the second and subsequent volumes don't follow on from the previous volumes?" UHC confirms this and is actively working on the problem. An anonymous SCOer says "The QIC02 tape controller `standard' is seriously flaky. Our driver's in pretty good shape but nobody will ever have a truly solid driver that supports every QIC02 controller you can find." Gordon Ross <gwr@mc.com> reports: "Actually, the SCSI tape target driver `st01' has a similar problem at version 4.0.3 which I corrected while I worked on the SVR4 code. The correction was provided to the support group at USL. The actual problem was that the SCSI tape would return a `check status' completion code which was just trying to inform the driver of the arrival of the `logical end of media' indication but the driver was treating it as an error. The tape drive had in fact written the data, but the driver incorrectly assumed that the "check status" return meant that it failed. The result of this is that when you write into the end of the tape, you can read back one more "chunk" than yu wrote. Of course, cpio does not like this at all when doing multi-volume backups..." 11. A kernel declaration bug A botch in USL's /etc/conf/pack.d/kernel/space.c (which is present in Consensys 1.3, Dell 2.1, Esix 4.0.3A, Microport 4.0.3 and 4.0.4 and may also be present in other SVr4s) can step on the linesw[] table. The problem is that the domain name array initialization is wrong and too short; thus, when it's set, data past the end of the array can be stomped. To fix this, find the following near line 247: char srpc_domain[] = SRPC_DOMAIN; and change it to char srpc_domain[SYS_NMLN] = SRPC_DOMAIN; then rebuild the kernel. Microport officially knows about this bug and plans to fix it in a near-future update release. It has been fixed in Dell 2.2. 12. fread(3) does the wrong thing on pipes and FIFOs Ed Hall <edhall@rand.org> writes: "Unlike the raw read() system call, fread() is supposed to be able to make several partial reads to satisfy the data requested by its arguments. The exceptions are an EOF or an error on the stream. This characteristic is quite useful when moving data through pipes or over network connections, since partial reads are quite common in these cases. Well, the version of fread() in ESIX 4.0.3 (and likely other Sys5R4's) only does a single physical read, and if it only satifies part of the requested number of bytes, that's all you get. This can sting you even if you carefully check the value returned by fread(), since the value returned is rounded down to the number of complete "nitems" read, although your position in the stream can be up to size-1 bytes beyond that point. Neither ferror() nor feof() indicate anything is wrong when this happens." This bug (which is also present in 4.0.4) is serious and nasty and should be high on every porting house's list to fix. It appears to be peculiar to USL 4.0.3 and 4.0.4; 4.0.2 does *not* have it, nor does SCO. A USL source claims it has been fixed in 4.1.